home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940243.txt < prev    next >
Internet Message Format  |  1994-11-13  |  7KB
  1. Date: Sun, 30 Oct 94 04:30:02 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: List
  6. Subject: TCP-Group Digest V94 #243
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sun, 30 Oct 94       Volume 94 : Issue  243
  11.  
  12. Today's Topics:
  13.          If they're gonna sell frequencies, what about these?
  14.                      PacComm HandiPacket (2 msgs)
  15.                     tftp/udp and a defect in bind
  16.                          Users and 9600 baud
  17.  
  18. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  19. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  20. Problems you can't solve otherwise to brian@ucsd.edu.
  21.  
  22. Archives of past issues of the TCP-Group Digest are available
  23. (by FTP only) from UCSD.Edu in directory "mailarchives".
  24.  
  25. We trust that readers are intelligent enough to realize that all text
  26. herein consists of personal comments and does not represent the official
  27. policies or positions of any party.  Your mileage may vary.  So there.
  28. ----------------------------------------------------------------------
  29.  
  30. Date: Sat, 29 Oct 1994 11:13:38 -0700 (PDT)
  31. From: California Wireless Incorporated <cwi@rahul.net>
  32. Subject: If they're gonna sell frequencies, what about these?
  33.  
  34. Fred R. Goldstein   fgoldstein@bbn.com  writes:
  35.  
  36. >I am not nearly as up in arms about this as many hams...
  37. >
  38. >How cum?  Look... do any of you USE any of that frequency band?
  39. >... (Stuff deleted)
  40. >We do such a bad job with the space we have I just can't get all
  41. >upset about this, so long as we end up with a few usable chunks.
  42. >... (Stuff deleted)
  43.  
  44. It is certainly true that some hams won't care about the future of ham radio,
  45. and won't care about experimentation with new and interesting modes, or about
  46. succeeding generations.  Some will be happy with their local 2m repeater and
  47. won't need more.  Some think that if you don't work it on HF, it doesn't 
  48. matter.
  49.  
  50. That's OK, ham radio is a diverse hobby, but we're all bonded by one thing:
  51. our need of frequencies upon which we can transmit!
  52.  
  53.  So, Fred, you may not have 2.4 GHz gear, or work Mode S, or be experimenting
  54. with wide-band spread spectrum, or using your local ATV repeater with an S
  55. band output, or...
  56.  
  57. That's OK!
  58.  
  59. But, please, Fred, don't write the FCC and tell them that you agree with their
  60. current ham frequency grab.
  61.  
  62. Please.
  63.  
  64. The way I see it, the FCC (and Hundt and his band of Beltway Bandits) is trying
  65. to get the golden eggs without the goose.  The goose (Ham Radio) lays the
  66. Golden Eggs (Trained engineers, technicians, enthusiasts available for the
  67. commercial industry).
  68.  
  69. The FCC, not happy with waiting for these eggs to be laid, instead wants to
  70. take a butcher knife and slice the goose open and get all of those golden
  71. eggs out.
  72.  
  73. Of course, all they will end up with is a dead goose, and no golden eggs.
  74.  
  75. But, presumably, the folks at the FCC never went through childhood and learned
  76. the moral of this story...
  77.  
  78.  
  79. I wonder what Hiram Percy Maxim would think!
  80.  
  81. -Mike k3mc
  82.  
  83. ------------------------------
  84.  
  85. Date: Sat, 29 Oct 1994 15:47:37 -0500 (CDT)
  86. From: Gerald J Creager <gerry@cs.tamu.edu>
  87. Subject: PacComm HandiPacket
  88.  
  89. I've misplaced my book, and need a little help, if someone might have the data
  90. available.
  91.  
  92. I need to get the pin-out for the mini-DIN connector, so I can try to get the
  93. Bovine Positioning System prototype up this weekend.
  94.  
  95. Thanks for the help,
  96. Gerry N5JXS
  97. gerry@cs.tamu.edu
  98.  
  99. ps:  Sorry Bruce, tamoo.edu was nix'd
  100.  
  101. gc
  102.  
  103. ------------------------------
  104.  
  105. Date: Sat, 29 Oct 1994 21:11:01 +0100
  106. From: "Brian A. Lantz" <brian@lantz.com>
  107. Subject: PacComm HandiPacket
  108.  
  109. On Sat, 29 Oct 1994, Gerald J Creager wrote:
  110.  
  111. > I need to get the pin-out for the mini-DIN connector, so I can try to get the
  112. > Bovine Positioning System prototype up this weekend.
  113.  
  114. Here, you go! We definitely want to keep that project MOO-ving  ;-)
  115.  
  116.  
  117. Pin 1 - Ground for both audio and PTT
  118. Pin 2 - Audio output from the HandiPacket to the transmitter
  119. Pin 3 - SPecial 'resistor' line for hand held radios
  120. Pin 4 - Digital data input from external modem
  121. Pin 5 - Push-to-talk to allow keying the transmitter
  122. Pin 6 - Transmit clock signal (X16) for external modem
  123. Pin 7 - Receive audio from the receiver speaker or auxiliary jack to the 
  124.         HandiPacket
  125. Pin 8 - Digital data output for external modem
  126.  
  127. -----------------------------------------------------------
  128. Brian A. Lantz/KO4KS                        brian@lantz.com
  129.  
  130. REAL PORTION of Microsoft Windows code:
  131.     while (memory_available)    {
  132.         eat_major_portion_of_memory (no_real_reason);
  133.         if (feel_like_it)
  134.             make_user_THINK (this_is_an_OS);
  135.         gates_bank_balance++;
  136.     }
  137.  
  138. ------------------------------
  139.  
  140. Date: Sat, 29 Oct 94 10:42:49 PDT
  141. From: Glenn Engel <glenne@lsid.hp.com>
  142. Subject: tftp/udp and a defect in bind
  143.  
  144. Phil,
  145.  
  146. In implementing tftp I discovered a slight problem.  The code uses
  147. the following sequence:
  148.  
  149. socket()
  150. bind()
  151. sendto()
  152.  
  153. While this works fine with unix systems, it does not work right with
  154. NOS. The problem arises from the fact that bind does not assign a local
  155. port so packets go out with a local port of 0 and the remote
  156. machine never replies since the port is zero.
  157.  
  158. The hp-ux man page states:
  159.  
  160.       When binding an AF_INET socket,
  161.       sin_port can be a port number, or it can be zero.  If sin_port is
  162.       zero, the system assigns an unused port number automatically.
  163.  
  164. I fixed this for udp with the following patch.
  165. --
  166. Glenn 
  167.  
  168. Glenn Engel / glenne@lsid.hp.com / Hewlett Packard / LSID / NN7N / 206-335-2066
  169.  
  170. *** /usr/tmp/fdif1AAAa04108     Sat Oct 29 13:30:00 1994
  171. --- udpsock.c   Sat Oct 29 13:16:33 1994
  172. ***************
  173. *** 29,34 ****
  174. --- 29,38 ----
  175.  
  176.         s = up->index;
  177.         sp = (struct sockaddr_in *)up->name;
  178. +
  179. +         /* If the call to bind specifies a local port of 0, assign one now */
  180. +         if (sp->sin_port == 0) sp->sin_port = Lport++;
  181. +
  182.         lsock.address = sp->sin_addr.s_addr;
  183.         lsock.port = sp->sin_port;
  184.         up->cb.udp = open_udp(&lsock,s_urcall);
  185.  
  186. ------------------------------
  187.  
  188. Date: Sat, 29 Oct 94 13:25:30      
  189. From: kz1f@RELAY.HDN.LEGENT.COM
  190. Subject: Users and 9600 baud
  191.  
  192. Karl wrote:
  193.  
  194.   "So lets admit that the new no code ham is.." ~incapable of running at 
  195. because they won't have a scope or deviation meters..
  196.  
  197.  Come on... I used to do 22 wpm and passed the novice, tech, advanced and 
  198. extra written exams. I happen to have a scope but do not have deviation 
  199. meters or a sophisticated test bench. I dont home brew and that has 
  200. absolutely nothing to do with how fast my code is. It is absolutely FM (and 
  201. the m stands for magic) that I got 5, much less 22 wpm on code. And that had
  202. absolutely nothing to do with my knowledge of theory or electronic design or
  203. knowledge of radio signal propagation. Notice, I didnt get gen, I got tech; 
  204. I didnt get extra, I got adv. <- points to code, doesnt it. 
  205.  
  206. I think the issue of code vs no-code is settled. There are alot of lurkers 
  207. on this group that are quite skilled in networking and/or radio theory 
  208. and/or pratical electronics that couldnt muster 1 wpm of morse code. They 
  209. may be absolutely brilliant at setting up really high speed radio links.
  210.  
  211. Perhaps what Karl (and 'we') ought to agree on, or argue over, is that 9600, 
  212. or better, operation is not something the casual, or appliance, operator
  213. should get involved in. 
  214.  
  215. -Walt
  216.  
  217. ------------------------------
  218.  
  219. End of TCP-Group Digest V94 #243
  220. ******************************
  221.